feat(github): share installations with web Cloud Agents - #5978

This reverts commit ee85e37.

This reverts commit bbecb73.

This reverts commit 25817c7.

dispatchSharedOnce recorded a completed delivery receipt whenever the
shared-installation receipt lookup wasn't missing_canonical,
regardless of the dispatched handler's response status. A non-2xx
dispatch was therefore marked completed, so a later GitHub
redelivery of the same event was short-circuited as a duplicate and
could never retry.

Only record the receipt when response.ok, leaving non-2xx dispatches
unrecorded so GitHub's redelivery can retry them. missing_canonical
behavior is unchanged.

beginProviderOAuthAttempt only expired pending/consumed rows whose
expires_at was already in the past before inserting the new attempt.
An unexpired pending row for the same owner+provider (e.g. an
abandoned flow) still collided with the partial unique index on
(owner, provider, status = 'pending'), blocking a fresh /connect
attempt for up to ATTEMPT_TTL_MS (10 minutes) and surfacing
oauth_init_failed.

Drop the expires_at filter for pending rows so a new attempt always
supersedes an existing pending one for that owner+provider, within
the same tx and owner-row lock already held. Consumed rows are still
only expired once actually past their TTL, since they don't hold
that unique slot.

consumeProviderOAuthAttempt's pre-step doesn't insert and matches the
row to consume by exact state_hash, so it doesn't share this
collision pattern and is unchanged.

results.flatMap(r => r.repositories) in fetchRepositoriesForIntegrations
had no dedup after dedupeRepositories was removed, so a corrupted or
duplicated cached repositories array on a single installation would
surface the same repo twice for that installation.

Deliberately keep one entry per (platformIntegrationId, id) rather
than deduping by repo id alone: NewSessionPanel already keys and
selects repository rows by platform + platformIntegrationId + id, and
the existing 'preserves both association choices when two
installations expose one repository' test documents that two
different installations granting the same repo must both remain
selectable, since session start resolves the token/permissions from
the chosen installation. Deduping by repo id would silently drop one
of those legitimate, functionally distinct entries.

Added a test covering the same-installation duplicate case and
confirmed the existing cross-installation test is unaffected.

Resolved apps/web/src/components/cloud-agent-next/NewSessionPanel.tsx
by taking main's refactored submit-path structure (hoisted
creationIntent/creationInput/bitbucketRepo memos, firstChatCreationOperation
as state) while restoring PR2's shared-GitHub-installation additions:

- RepositoryOption.githubAppType field
- githubAppType mapping onto GitHub repo options
- explicit "Select the GitHub repository again" guard before creationIntent
  is used in handleStartSession
- githubAppType included in the repo command-item search value
- the "Lite" badge for lite GitHub App installations

ENVIRONMENT.md auto-merged cleanly.

Three must-fix issues found in code review of the GitHub connections
work:

1. NewSessionPanel's GitHub-integration guard was unconditional on
   selectedGitHubIntegrationId, but that field is only ever populated
   for organization-scoped repos. Every personal (non-org) user
   selecting a GitHub repo hit 'Select the GitHub repository again'
   and could never start a session. Scope the guard to
   organizationId, matching the sibling conditional already used for
   creationIntent.

2. Both listGitHubRepositories tRPC output schemas silently stripped
   githubAppType (and the personal router also stripped
   platformIntegrationId/platformAccountLogin), making the new 'Lite'
   badge dead code and contributing to (1). Added the missing fields
   to both schemas.

3. refreshInstallation stopped syncing account/permissions/scopes/
   repository_access/installed_at onto the platform_integrations
   association row after the shared-installation refactor removed the
   legacy upsertPlatformIntegrationForOwner call. getInstallation/
   listIntegrations read those columns directly off
   platform_integrations, so GitHubIntegrationDetails kept showing
   stale data after a refresh. Added
   syncIntegrationInstallationDetails, scoped by integration id only
   (safe for shared/multi-owner installations, unlike the removed
   legacy writer), and wired it into refreshInstallation.

Added regression tests for all three: both listGitHubRepositories
routers now assert a full repo object round-trips unchanged through
the real tRPC output validation, and refreshInstallation's tests
assert syncIntegrationInstallationDetails is called with fresh data
(and not called on the early-exit failure path).

…liation

Split 0244 into three independently-tracked migrations so a failed or
interrupted deploy can never strand durably-committed DDL behind an
untracked migration, and never leaves a window with neither the old
nor the new uniqueness protection in place:

- 0244_salty_cyclops.sql: plain transactional additions only (new
  tables, new columns, all FK constraints including the validating
  platform_integrations FK). No explicit COMMIT/BEGIN, so Postgres
  rolls the whole file back atomically on any failure; a retry is
  always clean.
- 0245_calm_lockheed.sql: only the four CREATE UNIQUE INDEX
  CONCURRENTLY replacement indexes, fenced with the repo's approved
  COMMIT/BEGIN pattern. Does NOT drop the old two unique indexes.
- 0246_clean_the_renegades.sql: drops the two old unique indexes and
  adds the sharing_mode CHECK constraint, only after 0245 has been
  independently tracked as applied, so the replacements are always
  confirmed built before the originals are removed.

Verified empirically: applying only through 0245 leaves both the old
and new indexes coexisting (all valid) - there is no point in the
sequence where the uniqueness invariant is unprotected. 0246 then
applies cleanly as its own later migration.

Per packages/db/AGENTS.md, deliberately did not add IF NOT EXISTS or
a pre-emptive DROP INDEX IF EXISTS around the CONCURRENTLY builds:
the skill explicitly prohibits automatically masking a failed/invalid
concurrent index build that way and requires explicit operator
inspection and recovery (DROP INDEX CONCURRENTLY / REINDEX INDEX
CONCURRENTLY) instead. The file split already achieves retry-safety
at the migration-tracking level without needing that.

Also hardens 0243: replace the silent UPDATE that nulled any
dangling platform_integrations.github_installation_id with a DO 12662
guard that RAISEs if any orphan exists. Nulling was a behavior change
in disguise - for a row with github_app_type IS NULL, clearing the
reference makes it newly eligible for the legacy bot-link fallback
lookup (which treats github_app_type = 'standard' OR IS NULL as
equivalent). Since production orphan_count is confirmed 0, assert the
invariant instead of silently mutating data/eligibility.

Verified: drizzle-kit check passes; the full chain (including a
staged partial-apply through 0245 only, then 0246 separately) applies
cleanly from scratch against a fresh local Postgres; schema.ts is
unchanged (same end-state schema, just staged across more granular
migrations); packages/db/src/schema.test.ts (103 tests) passes.

Each of the four CREATE UNIQUE INDEX CONCURRENTLY statements in
0245_calm_lockheed.sql had no idempotency guard. CONCURRENTLY can
leave an INVALID index under its name if a build fails partway or is
interrupted; a blind retry of CREATE UNIQUE INDEX CONCURRENTLY on the
same name then fails with 'already exists' instead of rebuilding it -
the exact non-retryable strand Finding #1 addressed, just moved down
to the index-build step.

Precede each build with DROP INDEX CONCURRENTLY IF EXISTS on its
exact name: a no-op on the happy path (index doesn't exist yet), and
a clean removal of a leftover invalid index otherwise, so every retry
converges to the same end state. Per packages/db/AGENTS.md, deliberately
not using CREATE ... CONCURRENTLY IF NOT EXISTS, since that would leave
a leftover invalid index in place unrebuilt instead of recovering it;
DROP INDEX CONCURRENTLY is the exact recovery mechanism the skill
names, just applied proactively rather than only after manual
diagnosis. Both DROP CONCURRENTLY and CREATE CONCURRENTLY remain in
the existing post-COMMIT/pre-BEGIN section, outside any transaction
block, as required. No change to the final index set, names, or
schema.ts/snapshots.

Verified: drizzle-kit check passes. Full chain applies cleanly from
scratch. Directly simulated the failure mode: seeded a duplicate-data
conflict, forced one of the four builds to fail and leave an INVALID
index (confirmed indisvalid=false), confirmed a blind retry without
this guard fails with 'already exists' (reproducing the bug), then
repaired the data and confirmed the guarded migration now retries
cleanly to a fully valid final index set. packages/db/src/schema.test.ts
(103 tests) passes.